/barista review does the sanitize test need to be in a separate file?

Re-reviewing per @netchampfaris — focused on whether the sanitize test needs its own file.

Short answer: no, it doesn't have to be separate — but the split is reasonable.

• Vitest picks the environment per file via the @vitest-environment docblock; you can't mix node and jsdom in one file. The only reason Toast.sanitize.test.ts exists is that Toast.test.ts is pinned to node, and DOMPurify needs a DOM.
• Alternative: set Toast.test.ts to @vitest-environment jsdom, use the real DOMPurify everywhere, and drop the passthrough stub at Toast.test.ts:29. That collapses it to one file with no stub. jsdom would run the existing API-surface tests fine too.
• Keeping the split is also fine — it isolates the one DOM-dependent test and leaves the rest in the faster node env. Its only cost is the stub, which is harmless here since nothing in Toast.test.ts asserts sanitization.

So it's a judgment call, not a correctness issue. I'd lean toward whichever the repo already does elsewhere for consistency.

Looks good on the fix itself:

• toast.ts:18 — sanitizing the title and rendering via innerHTML is the right way to handle backend HTML; the ALLOWED_TAGS allow-list is tight and the XSS test in Toast.sanitize.test.ts:38 covers script/onerror stripping.
• description (legacy text) stays a plain string and sonner escapes it — good, only the title path goes through innerHTML.
• No new public props/slots/events — the success/error/warning/info wrappers just make explicit what Object.assign already exposed, with the same string | Component | VNode types.
• One minor thing worth a glance: every string title now becomes <span innerHTML> instead of sonner's plain-text title. Screenshots show it rendering fine, but if sonner applies any title-specific truncation/styling to text vs vnode titles, double-check a long single-line toast still clamps as before.

_{barista · claude-opus-4-8 · 8.3k in / 4.7k out · 555k cached · 75s · $0.485}

@netchampfaris
Different files seem fine, right?
If yes, we can merge this